An application programming interface (API) is an interface implemented on one or more computing devices by a software program that enables it to interact with other software. It facilitates interaction between different software programs similar to the way the user interface facilitates interaction between humans and computers. An API is implemented by applications, libraries, and operating systems to determine their vocabularies and calling conventions, and is used to access their services. It may include specifications for routines, data structures, object classes, and protocols used to communicate between the consumer and the implementer of the API.
Service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration. A deployed SOA-based architecture provides a loosely integrated suite of services that can be used within multiple business domains. Specifically, SOA embodies at least some of the characteristics of implementation independence, service reusability, loose coupling, service abstraction, and service composability.
Implementation independence refers to keeping services as implementation neutral as possible in order to facilitate maximum reusability. Service reusability refers to the goal of SOA to form applications that are built almost entirely from existing software services. Each service provides certain functionality, the larger the function is, the fewer the interface points are required. However, very large functionality may result in services that are not granular enough to be easily reused. The key is that there are no interactions between functions specified within the service. Loose coupling is a principle about interfaces having minimal assumptions between the sending and receiving parities. This reduces the risk that a change in one module will force a change in another module. Loose coupling means multiple dimensions. For the purpose of service contract, this principle focuses on using canonical model to decouple the service input output from proprietary data models. It also focuses on separating business logic from integration logic. Message routing, data transformation, integration patterns, and other integration related functions are handled by a software services infrastructure (SSI) so that services are decoupled from the underlying systems. Service abstraction refers to the relationship between a service and its underlying implementation. The right level of service abstraction is key to remove point-to-point interfaces. For example, advanced metering infrastructure (AMI) integration requires knowledge about meters and end devices. A service can be easily defined based on such information. The implication is that each consuming parties needs to understand the meters and end devices which requires data synchronization efforts for them to be synchronized with AMI system. An entity can have many products that need to interface with AMI data. Rather than providing a point-to-point interface between the products and the AMI data, a service defined on a more abstracted level, premise level, allows each individual system to have the knowledge about meters and end devices. A common component can be built to handle the relationship between premises and meters so that such integration and data synchronization only needs to be built once. The purpose of composability is to support service composition and orchestration so that new applications and processes can be built on top of existing services. Although this principle is related to service reusability and loose coupling, it provides extra guidelines for service identification. Each service should have a clear definition for its function and purpose so that it can be registered with a clear service semantics and ready for discovering. Redundant services should be avoided. No matter whether or not immediate composition requirements are already in existence, service composability should be considered for maximizing opportunity for service composition and orchestration.
Prior SOA systems used specific software code in an application client and in any implementation accessed by the client. For example, before the use of an Enterprise Service Bus (ESB), as known to one of ordinary skill in the art, any application client that wished to access implementations that existed remotely needed to include client code that communicated over the necessary transport for that implementation.
As shown in (prior art) FIG. 1, the application client 102 adopts a SOA approach and separates the “Server Code” 104 from the “Application Code” 106 via wrapper classes 108, where the wrapper classes encapsulate the necessary communication logic for the intended wire protocol (e.g., JMS, HTTP, Web Services, etc.), typically accessing the wrapper classes 108 using an interface that represents the service. In such architecture, the application client 104 is generally required to support client/server code for each type of transport it requires (e.g. JMS, HTTP, Web Services, etc); write and maintain the wrapper classes 106; and store the physical locations of each implementation in a configuration. At runtime, the application client 102 causes the application code 106 to invoke the wrapper class 108; the wrapper class 108 creates the necessary transport-level API objects; the wrapper class 108 creates the service message and sends it to the physical location of the implementation 110; the wrapper class 108 processes the response and converts it back from message to objects; and the wrapper class 106 returns the return object.
As shown in FIG. 1, each implementation 110 supports server code 104 for the chosen transport it uses to expose its functionality. At runtime, the server code 104 decodes the message received from the transport and invokes the necessary code for the service. At runtime, the server code 104 creates server components using the chosen transport API to listen for the incoming message; receives the message and decodes it into objects; invokes the implementation and receives the return object; encodes the response object into the message format; and returns the message via the transport API. The application client 102 includes a processor 114 for executing the application code 112 and other associated software. The implementations 110 can be associated with the processor 114 or one or more other processing devices (not shown).
FIG. 2 illustrates an embodiment of a SOA that comprises an ESB 202. An ESB 202 architecture is a logical architecture where components communicate over a bus. In one aspect, the bus supports standard Message Exchange Patterns (Request-Reply, Publish-Subscribe, etc). In one aspect, an ESB 202 uses physical transports (for example JMS, HTTP, TCP, In-Memory) to move data between ESB endpoints. Components on an ESB can typically be grouped into two main types: a) components that receive or deliver data; and b) components that operate on or manipulate the data.
The components that receive or deliver data operate either as a source or a destination (either final or intermediate) of the message data. Some components can function as both a source and destination. They can be varied in their functionality and include examples such as: JMS Queues and topics; files; databases; log files; Java Beans; Enterprise Java Beans (EJB); mail servers; HTTP servers; and the like. Each component receives the message data and processes it according to the operations it supports. For example, a file component can persist the message data to a file. A mail server can send the message data to a recipient (as described in the message headers). Each component can be configured on the bus as to how it operates and stores/sends the message data.
The components that operate on or manipulate the data simply act on the data before it moves to the next stage in the ESB route. Examples of such components are: transformation components (XSLT files, Java transformation components, etc.); content-based routing components; filters; splitters; aggregators; delays; multicasters; and the like. These components either change the content of the message, or change the next recipient of the message, or both. These components are sometimes referred to as Enterprise Integration Patterns (EIPs).
With the use of an ESB 202, both application client 204 and implementation 206 are greatly simplified. As shown in prior art FIG. 2, each implementation 206 delegates all the “transport-specific” code to the ESB 202. Therefore, the implementation 206 only has to be concerned with processing the incoming message and invoking the necessary code. The functions of the application client 204 are also simplified. It can choose how it communicates with the ESB 202, since the ESB 202 will abstract away the processes necessary to communicate with the implementation(s) 206. The ESB 202 can also (not shown) include routing information to decide which implementation 206 to use for a particular client 204 or message. The application client 204 needs to support client/server code for its chosen type of transport between the client and ESB 202 (for example, JMS); write and maintain the wrapper classes 208; and store the physical locations of each ESB endpoint 210 in its configuration. At runtime, the application client 204 invokes the wrapper class 208 with its application code 212; the wrapper class 208 creates the necessary transport-level API objects; the wrapper class 208 creates the service message and sends it to the physical location of the implementation 206; the wrapper class 208 processes the response and converts it back from message to objects; and the wrapper class 208 returns the return object.
Each implementation 206 decodes the message received from the ESB 202 and invokes the necessary code to provide the service. At runtime, the implementation 206 receives the message from the ESB 202 and decodes it into objects; invokes its business logic; generates a return object (if a response is required); encodes the response object into the message format; and returns the message via the transport API. The application client 204 includes a processor 214 for executing the application code 212 and other associated software. The implementations 206 can be associated with the processor 214 or one or more other processing devices (not shown).
However, in each of the above instances, the application client maintains additional code to interface with the service implementation. Therefore, methods, systems and computer program products that overcome challenges in the present state of the art, some of which are described above, are needed.